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Tliis report presents the various standard and device-dependent font formats in use at PARC. 

L Introduction 

A font is a collection of character descriptions, indexed by a character code. These descriptions 
represent, in one fashion or another, the appearance of the character. The ultimate purpose of 
maintaining a font is for use v^^hen generating a raster-scanned image of a document. This image 
may be created on a display and used for interactive purposes, or it may be generated by a printing 
service as part of a "hard copy" function. In both cases, for purposes of space and device 
independence, the document itself does not normally contain the character representations, but only 
codes used to identify the characters that comprise the document. 

It is important to distinguish font representations from font formats. 

We use tu'O generically different representations for character shapes. The first, loosely termed 
"splines" or "spline fonts," represents the outline of tlie each character shape with a series of 
parametric cubic spline curves (see Figure 1). This representation is handy because it is 
independent of tlie particular output device and its resolution: the outlines describe the desired 
appearance of the character. The second representation v/e use is a raster (sometimes loosely 
termed a "bit map"), as shown in Figure 2. This representation records, in some way, a two- 
dimensional (binary) occupancy map: it tells where the character lies on a two-dimensional grid. 
This representation is handy for actually building raster images of documents: the occupancy map is 
combined witli color infonnation, often at very high speed, to generate a larger raster image of the 
document. The raster character description is in effect merged into the page raster at the proper 
position. 

When characters are recorded in font files, we choose a particular format for the file; quite a 
number of different formats have emerged. This is because there are many ways to encode digitally 
the information in either an outline or raster representation of a character. The details of tlie 
encoding are often of vital concern when making a particular piece of hardware or software 
generate page rasters rapidly. 

Fortunately, we can write conversion programs that are able to generate die various specialized 
formats from standard formats. When an artist (or a needy user) devotes a large amount of effort to 
designing and debugging a font, it should be recorded and disseminated in one of the standard 
formats. Clients can then easily convert to one of the subsidiary formats, or to their own private 
format. 
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Widths 

An important adjunct to the font descriptions themselves is the "widths file," which summarizes the 
dimensions of all characters in the font data base. This summary must be available to a text editor 
when it formats a document for hard copy: the widths are used to determine how many characters 
will fit on a line and to perform justification calculations. Because tlie information in this file can 
be independent of any particular output device, the hard-copy file produced by the editor can be 
printed on any of a number of printing devices. The widths summary is, in effect, extracted from 
information recorded in tJie standard formats of tlie relevant fonts. 

There are several different flavors of width files now in existence. Some of them contain widths 
tiiat can be scaled to handle different sizes of a font; others apply to only one size. Some width 
files give the height and depth dimensions of the design box of each character separately, where 
others give only the font bounding box and the individual widths. The type of width file tliat gives 
each character's design box is used by tlie tex document compiler, and is not discussed in detail in 
tills memo. 

Software 

The PARC font descriptions are supported by a reasonably full set of software: 

niED: Interactive program for building outline font representations. Documentation is on 
<PrintingDocs>Frcd.Press. The program is on <ALTO>Fred.Dm. 

PREPRESS: Interactive program for building standard raster font representations. The 
program also contains numerous options for converting from standard to subsidiary formats. 
Documentation is on <Altodocs>PrePress.Press. The program is on <ALTO>PrePrcss.Run. 

COMPRESS (Obsolete): A program that converts .cu format to ears (.ep and .el) formats. 
The program is on <EARS>Compress.Run. 

Tlie reader is invited to consult PrePress documentation (<Aitodocs>PrePress.Press) for miscellaneous 
lore relating to fonts and for "standard operating procedures" for maintaining font files. 

People 

This document is simply a convenient summary of formats and techniques developed by a large 
number of individuals. The people behind the formats include Patrick Baudelaire, Peter Deutsch, 
Joe Maleson, Diana Merry, Ron Rider, Bob Sproull, Dan Swinehart, Larry Tesler, and Chuck 
Thacker. 

2. Terminology 

The terminology that has developed around fonts is hopelessly inconsistent. This section is intended 
to serve as a glossary for the descriptions in the remainder of this document. Be forewarned that 
terminology used elsewhere may not match. 

2.1 Characters 

Family is the term given to a particular design of characters. Examples of families are 
"TimesRoman", or "Helvetica". 

Point size of a character refers to size measurements used in the printing industry. If text is n 
points high, this means that closely-spaced lines of text will fall n/12 inches apart on the page. 
Note that the point size does not relate in any consistent way to the geometry of characters, e.g., to 
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the height of an upper case A. 

Face denotes a number of attributes of a particular font: italic, bold, light, condensed, expanded are 
all attributes of the font. Sometimes diis is called a "style." Sometimes the face is defined widi a 
tliree-letter code: the first letter is L for light, M for medium, or n for bold; the second is R for 
regular or i for italic; the third is C for condensed, R for regular or E for expanded. An optional 
fourth character can be used to specify the character coding used in the font: x for Xerox-style, a 
for ASCII, and for other. 

Rotation refers to the orientation of the character. If a string of characters is intended to be 
horizontal, it has rotation zero; if a string mns vertically upward, it has a rotation of 90 degrees. 

Font, as we use the term, refers to a collection of characters of the same family, the same size, the 
same rotation, and the same face attributes. 

Character code refers to a number (usually only 8 bits) that identifies a character. All our fonts use 
an approximation to the standard ASCII convention, when that convention is meaningful. For 
special-character fonts (e.g., mathematics, logic design), another mapping must generally be devised. 

Origin of a character (sometimes called "the (0,0) point") is conceptually a reference mark that is 
used to describe a character's location on a page or display. Thus a directive to "display an A at 
x = 103, y = 204" is interpreted to mean "place an instance of the symbol A on the display so that 
die character origin coincides with the coordinate x=103, y = 204." Figures 1 and 2 show the origin 
of a sample character. Note that the origin is located midway between pixels in each dimension, 
not in the center of a pixel. 

Width of a character is a two-dimensional vector that represents the incremental translation that 
should take place to determine the placement of the origin of the next character to be displayed in 
a (conventionally aligned) string of characters. In the example of Figure 3, if we assume the x 
direction points to the right and the y direction up, we see that the width vector has a zero y 
component. In this document, we will refer to the components of the width vector as Wx and Wy. 

In all our font representations, we associate the width vector with each character code. If this width vector is 
used for character positioning, the spacing between the origin of a A (say) and the origin of the next character 
is independent of that next characier. This is not always desirable: because of the different shapes of 
characters, spacing between differing pairs may want to be adjusted slightly to make the text line appear more 
pleasing. 

An empty character is one with an empty occupancy map; in particular, an empty character is some 
flavor of space. 

Bounding box is the term for a rectangle that just barely surrounds the character (see Figure 3). It 
is characterized by its width and height, and by a two-dimensional vector that specifies where the 
lower-left corner of the bounding box is witli respect to the origin of the character inside, .lliese 
four numbers are. named (in this document) UBdx, BBdy, BBox, and BBoy. 

An empty character, by convention, has both BBdx and BBdy equal to zero. BBox and BBoy make 
even less sense for an empty character; they are often set to zero as well. 

The font bounding box is a bounding box that applies to all characters in the font. That is, if all the 
characters in the font were placed with their origins coincident, the smallest rectangle tliat encloses 
every part is the font bounding box. The four parameters of the font bounding box are named (in 
this document) F'BBdx, FBBdy, FBBox, and FBBoy 

Tlie coordinate system assumed for this document is that x points to the right on a (portrait- 
oriented) page, and y points up. A mica is a unit of measure, equal to 10 microns or 1/2540 inch. 
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Both of these conventions are identical to those used by Press. 

Scanning mode refers to the way a raster is laid upon a character description. This in effect defines 
a coordinate system in which one direction is measured in scan-lines and the other direction is 
measured in bits (along a scan line). To describe the modes, we use a single number that relates the 
scanning regime to tlie conventional (x,y) coordinate system: the mode is bit-dircction-description*4 
+ scan-line-direction-description, where a direction-description is: 

if the coordinate increases as x increases 

1 if the coordinate decreases as x increases 

2 if the coordinate increases as y increases 

3 if the coordinate decreases as y increases 

This convention is identical to the one used by Press and MS. We use it in this document to 
characterize character encodings: if a raster is encoded in mode 8, then the first bit of the bit stream 
defining the character will be at the lower left-hand corner of tlie character; the next bit will be just 
above tlie first, and so on up the page (because the bit-direction-description is 2); then the next 
scan-line to the right will be given (because the scan-line-direction-description is 0). 

Note that there is a relation between rotation and scanning mode. For example, a character encoded 
with rotation = 0, scanning mode = 3 is identical to one recorded witli rotation = 90 degrees, scanning 
mode = 8. 

2.2 File terminology 

A file is a homogeneous sequence of data bits. (We at PARC do not have any file systems that have 
the concept of "record" as implemented in XDS and IBM operating systems. We view a file as an 
unbroken sequence of data.) 

A word is 16 bits, a byte is 8 bits. If these are to interpreted as signed integers, the representation is 
two's complement. 

Several files use the concept of self-relative pointers. The idea is that the pointer specifies a file 
position relative to tlie file position of the pointer itself, llie following example may help clarify 
the notion of self-relative pointers. Suppose that tlie character encoding for character 101b starts at 
word 1650b of the file, and that a self-relative pointer to that encoding is at word 105b of the file. 
Then word 105b of the file will contain 1543b = 1650b -105b. 

2.3 Numbers 

Numbers in this document are decimal unless followed by a "b," in which case they are octal.. 
12b = 10. 

A Floatingpoint number is a two-word structure that contains a sign, an 8-bit exponent and a 23-bit 
mantissa. This representation is identical to the 32 most significant bits of the representation used by 
tlie PDP-io and maxc. The Alto BCPL subroutine package FLOAT manipulates these numbers as well. 
(Further information about the actual encoding of numbers can be found in pdp-io documentation 
or in FLOAT documentation.) 

3. File Naming Conventions 

A standard naming convention is used for font files. In some cases, programs depend on adherence 
to the convention (e.g., extracting width information from liARS fonts). The convention permits 
programs to "parse" the font name to discover various parameters. The convention is: 
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{family-namc-in-full}{point-sizc}{[B|L]}{[i]}{[C|E]}. {extension} 

The optional B stands for "bold;" L for "light," I for "italic," C for "condensed," and E for 
"expanded." If a font file applies to all sizes of character (e.g., a spline file), the {point-size} is 
omitted. Examples: 

Helvetica 12.Ep 12-point Helvetica font for EARS 
Helvetical2b.Ep 12-point bold Helvetica font for EARS 

The {extension}s arc chosen to identify the format of the file. Standard extensions are given below, 
together with the maxc directory (inside brackets < >) where such files are traditionally found. 

Standard formats: 

.xx-SF Spline representations edited with FRED. <PRESSFONTS> 

.AC Raster representations, edited or created with PrePress. <pressfonts> 

(These are usually Alto or Press printer fonts.) 

Subsidiary formats: 

F'onts. Widths Summary of widths. <FONTS> 

.SD Compact spline representations (SDtemp format). <PRESSFONTS> 

.CU "Carnegie-Mellon University" format. 

Subsidiary formats (device-depcindeht): 

.AL Alto- format (CONVERT) font. <ALTOFONTS> and <PRINTING> 

.STRIKE Alto-format font (bitblt). 

.KS Alto-format font (bitblt) with kerning. <altofonts> and <printing> 

•EP ears- format portrait font (obsolete). 

.EL FiARS- format landscape font (obsolete). 

.XH XGP-fomiat font, for- xprint (obsolete). Archived from <fonts> 

.VT VTS-format font (obsolete). Archived from <fonts> 

.fonts Dictionary of fonts in .AC foimat or one of its subsidiary formats, used by 
Press printing software 

4. PrePress File Format 

Several of tlie file formats are variants of a generic file created and modified by PrePress. The 
format was designed to be easily extendable to include new sorts of information and to permit many 
different fonts to be included in one file. PrePress documentation refers to this files with names 
like SD, SDtemp, CD, CDtemp, WD, WDtcmp. An index at tlie head of the file describes each font 
segment tliat is contained within the file. The intention is that a reader will scan the index to find a 
pointer to the font she desires. Thus a file is: 

staicture PrcPressFile: 

[ 

index word howevcrMany 

@ix //Index entry with type=0 (end of index) 

stuff word howeverManyAgain 

1 

Each index entry begins with a common form of header: 
structure ix: 
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[ 

type bit 4 //Various type codes are assigned 

length bit 12 //Lengtli of entry in words, counting this one 

] 

A particular kind of index entry establishes a correspondence between a code and a string: 

structure ixn: 

[ 

@IX //Header widi type =1 

code word //The numeric code 

nameLength byte //The number of characters in the name 

characters tl,19 byte //Room for the name 

] 

Note that a name entry has a fixed length, although the name itself can be of any length up to 19. 
The final 20 bytes in the IXN structure are in the same format as a bcpl string. By convention, an 
IXN entry must establish a correspondence between a name and a code before any index entries that 
use the code appear. 

Each segment of tlie file will have an index entry that points to it (SplineSegment, 
CharacterScgment, or WidthSegment). They all have roughly tlie same form: 

structure STDix: 

[ 

@IX //Header with various types 

family byte //Family name, using a name code 

face byte ■ //Encoding of the face properties 

be byte //Code for the "beginning character" 

ec byte //Code for the "ending character" 

size word //Size of the font segment 

rotation word //Rotation of the font segment 

segmentSA word 2 //Starting address in file of the font segment 

scgmentLength word 2 //Lengtli of die segment 

] 

The family name is identified by referring to a name-code correspondence established with an IXN 
entry. The face is encoded as: 

(if bold then 2 elseif light then 4 else 0)+ 

(if italic then 1 else 0) + 

(if condensed dien 6 elseif expanded tlien 12 else 0)+ 

(if Xerox dien elseif ASCII then 18 else 36) 

This encoding generates face byte values in the range from through 53. Codes 54 through 254 
inclusive are used to denote the logical size of a TEX font, the size that the font was designed for 
independent of its physical magnification; for an explanation of this concept, see the memo 
[Maxcl]<Fonts>TexFonts.Press. A face byte value of F in the range [54,254] denotes a logical size 
of (254-F)/2 points; thus, logical sizes range from through 100 points in units of half-points. 
Face code 255 is reserved as an escape. 

The two entries be and ec give the character codes for die first and last characters represented in 
die segment. This allows pardal fonts to occupy less space. Size gives the size of die font 
description in micas. Rotation gives the rotation, in minutes of arc. scgmentSA and scgmentLength 
specify the location of the segment in the file (both entries arc double-word integers, in units of file 
words): these are included to permit random access to a large number of segments in one file. 
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A common special case of a PrePrcss file is a font file that contains only one segment, and 
consequently a very brief index (a name entry, and entry pointing to the segment, and an End 
entry). The AC and SD files are examples. 

5. Standard Formats 

5.1. Outline representation — SF format. 

The standard format for outline representations is a specially-organized text file. The file is 
normally read and written by frkd, tlic interactive editor for outlines, and by PrePress, the program 
for converting the outline representations to other formats. We designed the SF format to be based 
on a text file, and further to be readable by the interlisp programming system, in anticipation of 
die need to make transformations on outlines once they were defined (the transformadons could be 
made by hand with a text editor, or by writing a suitable lisp program). This approach has several 
times saved us from some very messy effort to repair a damaged binary file — the text file has been 
a good idea. 

The definidon of the file follows normal interlisp conventions for atoms, numbers, strings, and 
lists. (A number is eitlier an integer of die form 123 or an octal number followed by Q, i.e., 
12q=:10, or a floating-point number with an exponent heralded by E, e.g., 1.23E-4.) In the 
description below, vertical bar (|) is used to separate alternatives, and 

<...> is a list, 
{...} is a string, 
[...] is a number. 

A single SF file may contain definitions for several characters, although the definitions arc 
independent. The file is a sequence of <character descripdon>s, terminated by the atom STOP: 

<character descripUon> ... <character descripdon> STOP 

Normally, a full font will consist of about 7 SF files. These are conventionally given names like: 

family.LCl-SF Lower case, first file 

family.LC2-SF Lower case, conUnuation file 

family.uci-SF Upper case, first file 

family. UC2-SF Lower case, condnuation file 

family.NUM-SF Numerals 

family.Sl-SF Special characters, first file 

family.S2-SF Special characters, condnuation file 

A <charactcr descripdon> is: 

((FAMILY {family name}) 
(CHARACTER [code]) 

(FACl. ( B I M I R } { R I I } { C I R I E }) 

(WIDTH [width in x] [width in y]) 
(fiducial [dimension in x] [dimension in y]) 
(VERSION [number] {date}) 
(MADE-FROM {file name} 

[x character origin] [y character origin] 

[x fiducial origin] [y fiducial origin]) 
(SPLINES <closed curve> ... <closed curve>)) 

Alternatively, a <character descripdon> may specify that some other character is to be copied into 
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tliis one (not universally implemented): 
((family [family name}) 

(CHARACTER [code]) 

(USE {family name} [code] {bImIr} {r|i} {c|r|e})) 

Within the top-level list for <character description>, a construct of the form (comment {any 
string}) may be inserted at will. 

llie FACE characters stand for: 

BOLD I MEDIUM | LIGHT • 

REGULAR I ITALIC 

CONDENSED | REGULAR [.EXPANDED 

It is important to understand the normal use of coordinates in a SF file. The coordinates of knots, 
for the width, origins in the made-from description, and in tlie FIDUCIAL annotation, arc all Alto 
screen units: these are recorded dirccdy by fred. However, these coordinates must ultimately be 
related to a more standard system common to all characters in the world. The FIDUCIAL serves this 
purpose: it gives the distances, in x and y, that correspond to the point size of the character. For 
example, if we use fred to design a (nominal) 12-point character, we set the fiducials to the 
dimension (in Alto screen units) tliat should be mapped into 12/72 inch on the final page image. 

A <closed-curve> is: 

(<spline> ... <spline>) 

A <spline> is: 

([n] <knot list> <weight list> <derivative list> {solution metliod}) 
where [n] is the number of knots, <knot list> is: 

(([Xj [Yj) ([Xj [Yj)' ... ([Xj [Y„D) 

<weight list> is either NIL, in which case all knots are weighted equally, or: 

([wj [wj ... [wj) 

and <derivative list> is: 

(([Xi'l [Yi'l [X,"] [Yf] [X^-] [Yj-]) ... 

... {[X„.i'l iY„.i'] [X„.i"] [Y„.i"] [X^.-] [Y„.i-])) 
and {soludon mediod} is: 

{ NATURAL I CYCLIC | PSEUDOCYCLIC } 

The numbers in this descripdon are handled slighUy differenUy: derivadves and weights arc floating 
point numbers, character code is octal (e.g. lOlQ) or decimal, all other numbers (in particular knot 
coordinates) are integers. 

5.2 Raster representations — AC format. 

The standard format for raster representations is the AC file, usually edited with the PrePress font 
editor. This format is used because it contains more information about characters Uian any other 
font format we have. Consequendy, one can always convert to formats that demand less 
information. By convention, AC files assume a scanning mode of 8. 

ITie file is a segment of a "PrePress font file" (see secdon 4 for a general discussion of PrePress 
files). The font file contains some idenuficadon informadon, and a directory that points to a 
character segment, which itself contains the information about Uie font. An index entry that points 
to a character segment is: 
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structure CharactcrlndcxEntry: 
[ 

@STDIX 

resolutionX word 
resoIutionY word 



//Standard header with type = 3. 
//Resolution in scan-iines/inch * 10 
//Resolution in bits/inch * 10 



This index entry points to a CharacterSegmcnt: 
structure CharacterSegment: 



charData tbc,ec @CharacterData 
directory tbc,ec @relFilePos 
rasters tbc,ec @rasterDefn 



//Useful data about each character 
//Relative file positions of rasters 
//The actual raster encodings 



structure CharacterData: 

[ 

Wx ©Fraction 
Wy ©Fraction 
BBox word 
BBoy word 
BBdx word 
BBdy word 

] 



//X Width (scan-lines) 
//Y Width (bits) 
//Bounding box offsets 

//Width of bounding box (scan-lines) 

//Height of bounding box (bits) or special code 



The first two entries are signed fractions (a fraction is two words: die first is the integer part, the 
second the fractional part) that give the width vector (with reference to die origin of the character). 
The four parameters of the bounding box follow. However, BBdy= -1 is reserved to indicate that a 
character of this code does not really exist in the font (such a code is necessary because 
CharacterData stmctures are recorded for all character codes in the range be through ec). 

The directory portion is a table that points to the raster definitions of each character in the range be 
through ec. Each pointer is 32 bits long (a double-word integer) diat gives tlie position in the file 
in words, relative to the beginning of the directory table, of the rasterDefn for the appropriate 
character. If a character of the given code is not in the font, both words of die relFilePos are - 1. 

A rasterDefn is: 



structure rasterDefn: 

I 

BBdyW bit 6 

BBdx bit 10 

raster word BBdyW*BBdx 

] 



//Height of raster (in words) 
//Same as BBdx in CharacterData 
//The actual raster bits! 



The value of BBdyW is simply L(BBdy-j-15)/16J, the number of words required to specify one scan- 
line. Each scan-line in the raster encoding begins on a word boundary. 

Important Note: Most Press printing software uses dictionaries of fonts in one of two subsidiary 
formats derived from AC format. These important derived formats are described in sections 7.3 and 
7.4. 
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6, Subsidiary Formats 

6.1 Fonts.Widlhs format. 

The flic Fonts.Widths is used to disseminate width infomiation to all formatting and editing 
programs. Its basic format is that of a PrePress font file, with index entries that point to 
WidthSegmenls. An index entry is of the form: 

structure WidthlndexEntry: 

[ 

@STDIX //Standard header, type =4 

] 

The interpretation of the size entry in this index is somewhat subde. If it is non-zero, then it is the 
size of the font, measured in micas. Thus, a 12-point font would have size=A27). In this case, die 
width infonnation is said to be absolute. On the other hand, if size is zero, then the width 
information will be usable for fonts of any size (i.e., we shall scale it by the actual font size), and 
the infonnation is said to be fractional. If the data are absolute, then all dimensions are measured 
in micas. If they are reladve, dimensions cited in die WidtliSegment must be scaled by 
254QP/72000, where P is the point size of the desired font, in order to convert the numbers to micas 
(You will note that this simply means that entries are measured in thousandths of the point size). 
The widUis file may contain entries for bodi absolute and fractional information for the same font; 
in this case the absolute information takes precedence. 

The index entry points to a WidthSegment, which has the following format: 

structure WidthSegment: 

[ 

FBBox word //x offset for font bounding box 

FBBoy word //Y offset for font bounding box 

FBBdx word. //x width for font bounding box 

FBBcly word //Y height for font bounding box 

xwidthFixed bit // = 1 if all x widdis equal 

YWidthFixed bit // = 1 if all Y widths equal 

spare bit 14 

widthData word howEverMany 
] 

The first four numbers are the dimensions of die font bounding box. At the end of the entry comes 
(widthData) the width information for individual characters. First comes the X width information. 
If the xwidthFixed fiag is set, there is only one number given, which applies to all characters in the 
font. If the xwidthFixed flag is zero, then there are ec — bc + 1 words that give the x widths of die 
characters widi codes from be to ec inclusive. Then follows the Y width information, 
correspondingly encoded. In order to identify "non-existent" characters in the range be to ec, a 
width (either absolute or fractional) of 100000b (the most negative number) signals a non-existent 
character. 

Note: The widths file should really be able to deal with device-dependent widths as well: this is a tremendous help with 
photocomposers, etc. Consequently, a WidthlndexFntry should really include a deviceCode, which identifies (by 
correspondence with some string in a IXN entry) the relevant device. If the device is PRESS, then the font would be 
assumed to be standard across a variety of devices; a width entry with an exact match of device name would take 
precedence over standard (PRESS) widths. 

6.2. Compact outline representations — SD formal. 

Because the SF files that describe oudine representadons are somewhat bulky and tiresome to 
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interpret, there is an alternative format: SD. This format is created from tlie SP files by the PrePress 
READSF command (i.e., SD files are in the same format as is SDtemp). llie file is in the general 
"PrePress font file" format, with an index entry: 

structure SplinelndexEntry: 

[ 

@STDix //Standard header, type = 2 

1 

The size entry in the index must be zero. This index entry points to a SplineSegment: 

stmcture SplineSegment: 

I 

splineData tbc.ec ©SplineData. //Useful information about each character 

directory tbc,ec @reIFilePos //Directory pointing to spline encodings 

splines tbc,ec @splineCodcs //The encodings of each character 

The information about each character is: 

stmcture SplineData: 

[ 

Wx ©Floatingpoint //Width in x direction 

Wy @FloadngPoint //Widtli in Y direction 

BBox ©Floatingpoint • //Left edge of bounding box 

BBoy ©Floatingpoint //Bottom edge of bounding box 

Rightx ©FloadngPoint //Right edge of bounding box (=BBox + BBdx) 

TopY ©Floatingpoint //Top edge of bounding box (=BBoy+BBdy) 

All of these coordinates are relative to the origin of the character, and use the convendon that 1.0 is 
equal to the point size of the final character. .Consequently, most are usually fractional. A special 
(illegal) value of Wx is used to fiag SplineData structures tliat correspond to non-existent characters 
in the font (tliis problem arises because there are SplineData structures for all characters be through 
ec, even though they may not all exist). The special value is in the first word, and - 1 in the 
second word. 

ITie interpretadon of the directory is precisely the same as for AC files. 

The encoding of each character (splineCodes) is essendally a list of commands to a scan-conversion 
algoritlim, such as the one used in Pico. Five different kinds of entries may appear: 

structure SMoveTo: 

[ 

codeMoveTo word //Command code = 1 

X ©Floatingpoint 

Y ©Floatingpoint 
] 

structure SDrawTo: 

[ 

codeDrawTo word //Command code =2 

X ©Floatingpoint 

Y ©Floatingpoint 
1 
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structure SDrawCurve: 

[ 

codeDrawCurvc word 
X' ©Floatingpoint 
Y' ©Floatingpoint 
X"/2 ©Floatingpoint 
Y'72 ©Floatingpoint 
X"76 ©Floatingpoint 
Y"76 ©Floatingpoint 
] 

stiiicture SNewObject: 

[ 

codeNewObject word 

] 

stmcture SEndDcfinition: 

[ 

codcEndDefinition word 

] 



//Command code =3 



//Command code = — 1 



//Command code = — 2 



Each closed curve is specified widi a sequence tliat begins with SMoveTo, and uses subsequent 
SDrawTo and SDrawCurve entries to trace the outline. An entirely new object is initiated with 
SNewObject (this is presently unnccesssary, and unimplemented). The entire character is 
terminated with SEndDcfinition. 

The SDrawCurve entry gives the parameters for a parametric cubic spline: 

X = Xq + X' t + (x'72) P- + (x"76) t^ 
y = Yq + Y t + (Y'72) /2 + (Y"76) /^ 

where / ranges from to 1, and (Xq, Yq) is the starting point of the curve. 

The SD files created by PrePress from SF files have an additional property: each SDrawCurve entry 
defines a curve segment that is monotonic in both x and y directions. This simplifies scan- 
conversion for both portrait and landscape printing devices, provided the font characters are rotated 
a multiple of 90 degrees (or degress, of course). 

6.3 CU format. 

The CU format was once our standard format for raster representations; some vcsdgial software in 
fact still uses this format. It has the great virtue of simplicity, but is rather bulky and lacks some 
crucial information. 

The file has the structure: 



structure CU: 

[ 

II word 

WW word 

character tl,howeverMany 



//Height of font (number of scan lines) 
//"Word widtli" of font 
//Character codings 



Each character is a separate encoding with a character code, a width (in bits) for the character, and 
a raster. Every character in the file is placed witliin a raster of the same size: this raster size is' thus 
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analogous to the font bounding box, but is actually somewhat larger because the width of the box is 
a multiple of 16, 



structure cuChar: 

[ 

ASCliCode word 

Width word 

raster word IPWW 

1 



//ASCII character code 
//Widtli of character in bits 
//llie actual encoding of the raster 



The raster is a sequence of scan-lines, each encoded in ww words. The first scan-line is at the 
"top" of the character. Within a scan-line, bits arc given from left to right (more significant bits to 
less significant bits). Characters are, in general, "at the left" in tlie font bounding box; white space 
is provided on the right. 

This font format omits some useful information: the location of the origin within the bounding box. 
lliere is a convention used to remedy this lack: the lower leftmost 1 bit in the encoding of upper 
case A (ASCII code 101b = 65 decimal) is at the origin. 

7. Subsidiary formats — device dependent 

7.1 AL format. 

The AL format is designed to simplify the use of the Alto convert instmction for creadng displays 
(see the Alto Hardware Manual for a description of convert). 



structure al: 

[ 

Height word 

proportional bit 

baseline bit 7 

maxWidth bit 8 

pointers tO,nCharsX 

charData word howEverMany 

] 



//Height of font (scan-lines) 
//True if proportionally spaced font 
//(see below) 

//Width of widest character 
//Self-relative pointers to xw entries 



The Height entry must be > FBBdy. The baseline entry equals the height of the font bounding box 
above the origin (=FBBoy+ FBBdy). If the AL font dates from a somewhat earlier vintage, the baseline 
may be recorded as 0. 

The pointers table contains self-relative pointers to character encodings. Each character encoding in, 
the charData region can describe at most 16 (horizontal) bits of character data; if the character 
requires more data bits, an "extension character" is used to contain the rest of the data. Characters 
may have as many extensions as necessary. 

By convention, the first 377b entries in the pointers table are assumed to be self-relative pointers for 
tlie corresponding ASCII characters codes. Following these entries are entries for any necessary 
extension characters. 

The data for a character encoding is represented as: 



structure xildata: 

[ 

bitData word XH 
XW word 



//Top scan-line first 
//(see below) 
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I ID byte //(see below) 

XII byte //Number of scan-lines of bit data 

] 

In order to conserve space, the bit data omits all-zero words at the top and bottom of the character. 
The I ID entry records the .number of scan-lines at the top of the character (relative to the font 
bounding box) that are omitted. (Technically, I ID = FBBdy + FBBoy-(BBdy + BBoy).) 

The xw word is interpreted in one of two ways. If the width of the character is 16 or fewer bits, 
then xw is (2*width) + l. Otherwise, the character must require an extension character, and XW 
contains 2*xCode, where xCode is the character code of the extension character. The final 
extension character will have an xw- that contains (2* width of final extension)+l, rather than the 
total width. The self-relative pointers in the pointers table point to the xw word. 

By convention, the first character encoding in the charData region is a "dummy" to which all non- 
existent character codes point. This dummy has XH = 0, hd=:0, and xw = l. 

7.2 PLAINSTRIKE and KERNEDSTRIKE format. 

The STRIKE formats were devised to permit graceful use of bitblt for writing character3 onto the 
Alto screen. Like .AL format, the strike formats can only handle fonts with zero rotation, that is, 
with nonncgative X widths and zero Y widths. 

There are four kinds of files in the Strike class: a PlainStrike file (conventional extension .Strike), a 
KernedStrike file (conventional extension .KS), a PlainStrikcIndex file (conventional extension 
.StrikeX), and a KernedStrikelndex file (conventional extension .KSX). In a PlainStrike file, the 
individual rasters of the characters are assembled in ascending order of character code into one large 
raster, called the strike. The baselines of the characters are aligned, and the origin of each character 
is made coincident witii the end of the width vector of the preceding character. The PlainStrike file 
also contains a table indexed by character code that points to the leftmost column of die raster for 
each character in the strike. Warning: since the rasters in a PlainStrike file are positioned by their 
origins and width vectors, it must be the case that all of the black bits of the character lie between 
these two bounds. No character may include bits to the left of its origin (left-kerning) or to the 
right of the end of its width vector (right-kerning). 

A KernedStrike file handles kerned characters, and does so in the following way: the individual 
rasters are put into the strike by their bounding box widths. Just think about taking the bounding 
boxes of all of the characters, lining up their baselines, and packing them tightiy into one long 
raster array; in tliis format, there are no blank columns between characters in the strike. A 
KernedStrike file has three additional tables, indexed by character code. One gives the position in 
the strike of the first column of tlie character's raster, which is also the leftmost column of its 
bounding box. The other two tables consist of small integers that specify the left-to-right location 
of the origin witli respect to the bounding box, and die lengtii of the width vector. 

A Strikelndex is essentially a table that maps character codes into <strike, code> pairs, together with 
Uie associated strikes. An index can be used to achieve sharing if several character codes map to 
die same <strike, code> pair, and hence refer to Uie same raster. Or it can help to save space, by 
grouping the rasters into several strikes to save top and bottom scanlines. [By tlie way, to the best 
of my knowledge, no one has ever used a Strikelndex format.] 

PlainStrike and KernedStrike files have the following format: 
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stmcturc PlainStrike: 

[ 

©StrikcHcadcr 

©StrikcBody 

] 

structure KernedStrike: 

[ 

@StrikeHcadcr 

@BoundingBoxBlock 

@StrikcBody 

©WidthBody 

] 

stmcturc StrikeHeader: 

[ 

format word = 

[ 

oneBit bit 
index bit 
fixed bit 
kerned bit 
blank bit 12 

1 

min word 
max word 
maxwidth word 
] 



// header common to all Strike files 
// the actual strike 



// header common to all Strike files 
// dimensions of the font bounding box 
// the actual strike 
//table of width data 



// always = 1, meaning "new style" 

// = 1 means Strikelndex, = otherwise 

// = 1 if all characters have same value of Wx, else =0 

// =1 if KernedStrike, =0 if PlainStrike 



// mimimum character code 
// maximum character code 
// maximum spacing width of any character = max{Wx} 



stRicture BoundingBoxBlock: 
[ 



FBBox 
FBBoy 
FBBdx 
FBBdy 
] 



// as defined above 
// as defined above 
// as defined above 
// as defined above 



structure StrikeBody: 

[ 

length word 
ascent word 

descent word 

xoffset word 

raster word 

bitmap word raster*height 

xinsegment t min, max + 2 word 

] 



// total number of words in the StrikeBody 

// number of scan-lines above the baseline, which is 

// normally max{BBdy+ BBoy] over the chars in tliis strike 

// number of scan-lines below the baseline, which is 

// normally max{( - BBoy)] over the chars in this strike 

// always = [used to be used for padding schemes] 

// number of words per scan-line in the strike 

// the bit map, where height = ascent + descent = FBBdy 

// pointers into the strike, indexed by code 



structure Width Body: 
[ 
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width table t min, max + 1 ©WidthEntry // spacing information, indexed by code 

stnjcture WidtliEntry: 
[ 

spacing word = // tlie entire spacing word will be = ( - 1) (both bytes = 377b) 

// to flag a non-existent character, else tlic bytes are: 
[ 

offset byte // =BBox-FBBox 

width byte // =Wx 

] 
] 

The "bitmap" entry is one large bit map; there are heights ascent + descent scanlines in the 
bitmap, each of which is raster words long. Unless something funny is going on, ascent will be 
simply FBBdy + FBBoy, while descent will be simply (-FBBoy). 

The font includes characters for some of the ASCII codes from min through max inclusive. The 
bitmap includes a dummy character associated with the charcter code (max + 1), which can be 
displayed for any non-existent character. 

A PlainStrike works as follows: Given a character code c, in the range [min, max], we first 
compute: 

xLeft *- xinsegment t. c; 

xRight ^ xinsegment t (c-f-1);. 
If xLeft=xRight, then.c is a non-existent character in the current font, and should be replaced by 
tlie raster widi code (max-fl). Otherwise, the columns of the bitmap from xLeft through 
(xRight-1) inclusive contain the raster for character c, and the width of charcter c is 
Wx = (xRight-xLeft). 

A KernedStrikc works a litUe differently. We first compute xLeft and xRight as above, and also 
compute 

Spacing *- WidtiiTablc t c;. 
If Spacing = (-i), then c is a non-existent character in the current font, and should be replaced by 
the dummy character at (max + 1). Otherwise, tlie columns of the bitmap from xLeft through 
(xRight- 1) constitute the bounding box of the raster of character c. In this case, we decompose 
tlie Spacing value into its two bytes: 

Offset ♦- Spacing«WidthEntry.offset; 

Width ^ *- Spacing«WidthEntry.widdi;. 
Now assume that we want to paint die character c starting at destination column xDest. The source 
of the BitBlt is columns xLeft Uirough (xRight- 1) of the bitmap inclusive. We can compute the 
proper destination from xDest, Offset (which = BBox-FBBox), and the FBBox word of the 
BoundinglioxBlock: the first column of the destination is (xDest+Offset+ FBBox) = (xDest-fBBox). 
Note: the offset portion of the WidthEntry was chosen to be (BBox-FBBox) rather than BBox 
itself, since the former quantity is always nonnegative, while the latter quantity can have either sign; 
and signed 8-bit numbers are a pain in the ass. Finally, we replace xDest by (xDest+ Width) to 
prepare for the paindng of the following character. 

Two fine points concerning KernedStrikes: A non-existent character is flagged by a (-1) value in 
die Widthlable. Since a non-existent character doesn't have a bounding box, die xLeft and xRight 
entries for such a character will be equal. Ikit there can also be perfectly legal characters for which 
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xLeft=xRight; in particular, all of the empty characters will have this property: figure space, em 
quad, word space, etc. If you arc painting an empty character, there is no need to actually perform 
the BitBlt, since the rectangle being Blt'ed would have- zero width. All that must be done is to 
replace xDcst by (xDest+ Width) to make the space happen. Secondly, some extra efficiency can 
be gained when using a KernedStrike font by keeping track of the quantity (xDest+MM^ox) in the 
character-painting loop, instead of xDest itself. This moves one addition out of the inner loop. 

Finally, it is dmc to say a few words about Strikclndex format: a Strikelndex is simply an index at 
the front of some StrikeRodies. 



structure PlainStrikelndcx: 

[ 

©Strikel leader 

maxascent word 

maxdescent word 

nStrikcBodies word 

map t min,max-f-l @mapEntry 



// common header 

// maximum ascent of all the strikes 

// [probably =FBBdy + FBBoy] 
// maximum descent of all the strikes 

// [probably =(-FBBoy)] 
// the number of strike bodies 
// table of <strike, code> pairs, dummy at max-f 1 



bodies 1 1, nStrikeBodies ©StrikeBody // the strike bodies themselves 



stRicture KernedStrikelndex: 

[ 

©StrikcHeadcr 
@BoundingBox Block 
maxascent word 

maxdescent word 

nStrikeBodies word 

map t min,max + 1 @mapEntry 

bodies t I, nStrikeBodies @StrikeBody 

©WidthBody 

] 



// common header 

// bounding box data for the entire font 

// maximum ascent of all the strikes 

// [probably =FBBdy + FBBoy] 
// maximum descent of all the strikes 

// [probably =(-FBBoy)] 
// the number of strike bodies 
// table of <strike, code> pairs, dummy at max+ 1 
// the strike bodies diemselves 
// table of width data 



structure mapEntry: 

[ 

missing bit 1 
strike bit 7 
code byte 
] 



// = 1 if character is non-existent, else =0 
// which strike, a number in tlie range [0:127] 
// which character code in that strike 



In a Strikelndex font, all of the StrikeBodies have implicit min values of zero; the max value is 
unimportant, as the map will never generate a reference outside the range. The individual 
StrikeBodies do not have separate pictures for illegal characters; instead, the (max-fl) entry in the 
global map defines a single dummy picture. Non-existent characters in the range [min, max] are 
indicated in the global map by a mapEntry that specifies a strike number larger dian 127 = 177b, 
that is, by the sign bit of the map entry being 1. In KernedStrikelndex fonts, non-existent 
characters will also be indicated by having a WidthEntry of (—1). 
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In Strikelndcx fonts, the ascent and descent words in each StrikeBody give the dimensions of that 
parucular StrikeBody; thus, they probably are the y dimensions of the bounding box of those 
characters that are included in that StrikeBody, rather than of the entire font 

Note on DilBlt modes: 



There are evidendy lots of programs in the world that paint charcters on the screen by calling BitBlt 
in Replace mode, in which the new bits simply smash whatever used to be at the destination. If 
you want to handle characters that kern, you simply can't do this! The bounding boxes of 
successive characers may actually overlap, and hence a Replace Bit might overwrite valuable bits. If 
you want kerning specified in a KernedStrike font to work, you must use one of the other BitBlt 
modes: Paint, Erase, or Invert. 

7.3 Compact ("Orbitized") format for raster representations 

Both the PRESS and the spruce printing systems use dictionaries whose font formats have been 
compacted by eliminating the requirement that scan lines begin on word boundaries. The storage 
for a character can be thought of as a stream of bits, with the first bit of each scan line following 
the last bit of the preceding one, irrespective of word boundaries. The encoding is identical to the 
AC format encoding of section 5.2, except for the type and the raster definition. For convenience, 
we repeat the entire specification here. An index entry that points to a compacted, or "Orbitized", 
character segment is: 

structure CompactedCharacterlndexEntry: // identical to type 3 except for type 

@STDix //Standard header with type = 5. 

resolutionX word //Resolution in scan-lines/inch * 10 

resolutionY word //Resolution in bits/inch * 10 
1 

This index entry points to a CompactedCharacterSegment: 

structure CompactedCharacterSegment: // identical to type 3 format except raster encodings 

charData tbc,ec ©CharacterData //Useful data about each character 

directory tbc,ec ©relFilePos //Relative file positions of rasters 

rasters tbc,ec @compactedRasterDefn //The actual raster encodings (These vary in length, 

// thus could not actually be indexed) 
] 

stnicture CharacterData: // identical to standard type 3 AC format 
[ 



Wx ©Fraction 
Wy ©Fraction- 
BBox word 
BBoy word 
BBdx word 
BBdy word 

] 



//x Width (scan-lines) 
//Y Width (bits) 
//Bounding box offsets 

//Width of bounding box (scan-lines) 
//Height of bounding box (bits) 



A compactedRasterDefn is: 

stmcture compactedRasterDefn: 

[ 

negHeight 



//Negative of the character height, in bits 
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widthMinusl 
raster word n 



//Width of the character, less 1, in bits 
//The actual raster bits! 



Ttic value of n, the number of words occupied by raster bits, is the floor of (height*width + 15)/16. 

7.4 Compacted rasters with multiple width specifications 

In order for the producer and the printer of a PRESS format file to agree on the appearance of each 
page, they must agree on the widths of the characters to be printed. This agreement is achieved by 
providing the producer programs with WIDTHS fomiat files corresponding to the raster files used by 
the printers. 

On infrequent occasion, the widths' specified for existing characters in existing fonts must be 
changed. Once the new widths and raster files have been promulgated, all newly-created press 
format files will again print correctly, but older files will no longer be rendered accurately. 

To improve this situation, it is possible to create a font dictionary whose entries include for each 
font a single set of raster definitions, along with a collection of width specifications, each 
accompanied by an expiration date. The printer spaces characters based on the widths that were in 
effect at the time indicated by the PRESS file's creation date (stored in its document directory). If 
the new rasters are predominandy narrower, or at least not too much wider, than the characters they 
replace, the result of printing an old press file is usually satisfactory. 

The PrePress system contains a special command for introducing a new set of rasters for a font, 
retaining both all of the old widths along with the new ones, llie administrators at a site may 
choose to support this capability, -or to ignore it. 

This format requires modification of die STDix stRicture. Its rasters are in the compacted 

representadon described in the preceding section. A font file for a printer may contain any 

combination of type 5 (compacted) and type 6 (compacted, multiple widths) font formats. The 
index entry for a font with muldple widths is: 



structure MultipleCharacterlndexEntry: 

[ 

@ix 

family byte 
face byte 
be byte 
ec byte 
size word 
rotadon word 
resolutions word 
resolution B word 

numSegs word 
segstl,numScgs: 

[ 

segmentSA word 2 
segmentLength word 2 
expiradonDate word 2 



] 



] 



//Header, type = 6. 
//Family name, using a name code 
//Encoding of the face properties 
//Code for the "beginning character" 
//Code for the "ending character" 
//Size of die font segment 
//Rotation of the font segment 
//Resolution in scan-lines/inch * 10 
//Resolution in bits/inch * 10 

//Number of width segments 

//Arranged in order from newest to oldest 

// Only the newest entry includes rasters 

//Starting address in file of the font segment 

//Lengtli of the segment 

//Date after which these widths are no longer valid, 

// in Alto file date format 



Tlie segment corresponding to scgstl is a CompactcdCharacterSegment, as described in die 
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preceding secdon. Its widths represent the current vahies; its expiradon date is set well into the 
future. Segments corresponding to segst2 through segstnumSegs represent increasingly older width 
values; they have the form: 



structure OldWidthScgment: 

[ 

charDatatbccc ©CharacterData 

] 



//Useful data about each character 



The raster-specific informadon in this specificadon is identical for all segments; the widdi entries 
that define the spacing characteristics will differ. 

7.5 EL and EP format for EARS fonts (obsolete) 

Font formats for the EARS system are compressed (all other raster representation formats mentioned 
in this document use no compression). The extension .EP is used, by convention, to denote 
"portrait" fonts (font strings will mn horizontally on the page if it is oriented as a portrait). The EL 
extension is used for "landscape" fonts. 

Both sorts of font have the same fonnat (remember that ears scans in mode 8): 



stnicture elep: 

[ 

©RecordO 

@Recordl 

Record2 word howEverMany 

@Record3 

] 

stmcture RecordO: 

[ 

MRLlLength word 
maxWidth word 

maxHcight word 
TTYTab word 
defaultFSN word 
reserved word 3 
blank word 56 
] 

structure Recordl: 

[ 

characterData t0,127 @RecordlEntry 

] 

stmcture RecordlEntry: 

[ 

FontAddress word 

FontLcngth word 
Widtii word 
W word 
11 word 
baseline word 
codingType word 



//General infomiation 
//Character information 
//Actual character encodings 
//Font specification table 



y/Lengdi of Record2 (in words) 
//Maximum character width (scan-lines) 
// max (over all RecordlEntry's) of Width 
//Maximum character height (bits) FBBdy 
//How many bits or scan-lines for a tab 
//Default font set number (PSPOOL) 
//Used, by PSPOOL 



//Descriptions of each character 



//Address (in words) into Record2 of encoding 
// (relative to beginning of Record2) 
//Number of words of encoding in Record2 
//"Width" of character (amount to "space" over) 
//Width of bounding box BBdx 
//Height of bounding box BBdy 
// BBoy (portrait) or BBox (landscape) 
//(see below) 
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alignment word // FBBdx + FBBox-BBox (landscape only) 

] 

^rhc codingType is if the cliaracter does not really exist in the font. It is <0 if the encoding within 
Record2 is RLI (nin length increments). It is >0 if the encoding is a matrix (in this case, the value 
of codingType is tlie height of the matrix in bytes). 

Rccord2 contains the encodings of the rasters for the individual characters (as pointed to by 
Recordl and Record3 entries). If the encoding is a matrix, the entry in Record2 in an 
uncompressed raster for the character (scanning mode = 8), with (1) the height rounded up to the 
next multiple of 8 bits, and (2) a possible 1-byte padding at the end of the matrix encoding to make 
the entry an integral number of 16-bit words long. For example, the K of Figure 4 would have a 
matrix encoding of: 

100004b ' (first scan-line, rounded up to 16 bits high) 

177777b (second scan-line, ...) 

177777b 

103004b 

001400b 

003600b 

006300b 

014140b 

130064b 

160034b 

140014b 

100004b (last scan-line) 

Most characters will be encoded in Record2 with a more economical scheme: RLi. This is a 
compression scheme that reduces font storage for high-resolution characters (compression of 3.5:1 is 
typical for a 12-point font at 500 bits/inch). We shall describe RLl by referring to Figure 4. Each 
scan-line could be coded as a series of number pairs, where the first number of each pair represents 
a number of "white" bits to be followed by the number of "black" bits specified by the second 
number of the pair. With this scheme, the first scan-line of the K would be represented by tlie two 
pairs (0,1) and (12,1).. We can omit the parentheses and write simply 0,1,12,1. The entire K is 
encoded into runs as follows: 

RLI 



Scan-line 


Runs 





0,1,12,1 


1 


0,14 


2 


0,14 


3 


0,1,4,2,6,1 


4 


6,2 


5 


5,4 


6 


4,2,2,2 


7 


3,2,4,2 


8 


0,1,1,2,6,2,1,1 


9 


0,3,8,3 


10 


0,2,10,2 


11 


0,1,12,1 



(R) 


0,1,12,1 


(R) 


0,14 


(I) 


0,0 


(R) 


0,1,4,2,6,1 


(R) 


6,2 


(I) 


-1,2 


(R) 


4,2,2,2 


(I) 


-1,0,2,0 


(R) 


0,1,1,2,6,2,1,1 


(R) 


0,3,8,3 


(I) 


0,-1,2,-1 


(I) 


0,-1,2,-1 



The second column gives simply tlie runs. The third column gives the mn-\cr\g\h- increment format: 
a given scan-line is represented as increments on the iiins for tlie previous scan-line, provided there 
are the same number of runs as in the previous scan-line. Thus scan-line 10 is represented by the 
increments 0,-1,2,-1, which are added to the runs for scan-line 9 (0,3,8,3) to yield runs 0,2,10,2 
for scan-line 10. For high resolution characters (our example is not high resolution), the 
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incremental mode (I) dominates. 

The RLI information is encoded as follows. The character encoding starts in Record2 at the location 
specified by l^ccordl and Records entries; RLI information is recorded for each scan-line (starting 
with the left-most scan-line, scan-line in our example). Runs appear in 8-bit bytes, where the first 
bit of a byte is a flag which is set to mark the last run for a scan-line. Thus, scan-line 9 is 
represented by the 4 8-bit bytes 0, 3, 10b and 203b; these are packed into words as 3b and 4203b. 
Because of this encoding, runs are limited to the range 0-127; if a longer run is needed, two runs 
may be spliced with a zero-length connector (e.g., 100,0,100,10 is equivalent to 200,10). A limit of 8 
Rins is imposed for each scan-line (characters requiring more than 8 mris can be represented in 
matrix format). 

The increments for Rli arc specified in 4-bit groups in which the first bit is used as a flag and tlie 
remaining 3 bits are 2's complement increments (range —4 to 3). As with runs, the flag bit for the 
last increment of the scan-line is set. In addidon, the flag bit of the first increment on the scan-line 
is set (this allows runs to be differentiated from increments, because there are always at least 2 runs 
per scan-line). For example, tlie increments to scan-line 10 are encoded as the 4-bit quantities 10b, 
7b, 2b, 17b; these are packed into 8-bit bytes as 207b, 57b; or into a 16-bit word as 103457b. Note 
that if increments do not fall in tlie range -4 to 3, you can always use a run representation rather 
tlian an increment representation. 

This encoding will produce an integral number of 8-bit bytes for each character. Consequently, a 
character may be followed by a 1-byte padding in order to stard die subsequent character at a word 
(16-bit) boundary. 

Record3 is a very compact description of each character, and is actually examined by the rcg 
hardware: 

structure Record3: 

[ 

fontSpecTable t0,127 @CharSummary 

] 

structure CharSummary: 

[ 

baseline bit 13 //Two's complement baseline (0 for landscape) 

matrix bit //True if encoding is a matrix (not RLl) 

endOfPage bit 

notEndOfLine bit 

Width word . //Amount to space over to next character 

W bit 10 //Bounding box width -1 

Hbbit7 //L(Height+7)/8J -1 

fontAddress bit 15 //Relative address in Record 2 of encoding 

7.6 XII formal XGP fonts for X PRINT (excruciatingly obsolete) 

The xil format was devised to simplify the inner loop of xprint, a program for printing text on die 
XGP. The XGP scans in mode 3. llie file has the format: 

structure XH: 

[ 

nChars word //The number of characters in the font 

nData word //Number of words of font data 

II word //Height of the font (in scan-lines) 

w word - //Maximum width (in words) of any character 
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pointers tO,nChars- 1 word //Self-relative pointers to charData (see below) 

widths rO,nChars-l word //Width to space to next character 

data word nData //Character encodings (sec below) 

nChars is usually 128 or 256. The height il must be > FBBdy. A width of zero identifies a non- 
existent character; any widtli up to 12 W is legal. 

llic character encodings are represented as follows: 

structure charData: 
[ 

tl,L(width+ll)/12J ©block //Each block defines up to 12 bits 

] . 

structure block: 
[ 
tl,ii [ bitData bit 12 //Up to 12 bits of character data 

validBits bit 4 ] //Number of bits in bitData that are valid 

] 

Tims a character is defined by successive blocks of ii words; each block defines up to 12 horizontal 
bit positions of the character. The first word in the block defines the top scan-line, the next word 
the next scan-line, etc. Words of the block define up to 12 bits of character data: the validBits field 
contains the number of valid bits in the word (1 is minimum; 12 is maximum). All blocks except 
the last have validBits = 12. 
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Character Codes of First Generation Fonts (somewhat obsolete) 

(For the up-to-date story about character code assignments, see the memo 
[Maxcl]<i""'onts>SpecialCharacters.Press) 

a 141b 

b 142b 

c 143b 

d 144b 

. e 145b 

f 146b 

g 147b 

h 150b 

i 151b 

j 152b 

k 153b 

1 154b 

m 155b 

n 156b 

157b 
p 160b 
q 161b 
r 162b 
s 163b 
t 164b 
u 165b 
V 166b 
w 167b 
X 170b 
y 171b 
z 172b 
{ 173b 

1 174b 
} 175b 

176b 



underline 


30b 


space 


40b 


1 


41b 


fi 


42b 


# 


43b 


$ 


44b 


% 


45b 


& 


46b 


' 


47b 


( 


50b 


) 


51b 


* 


52b 


-f 


53b 


» 


54b 


- 


55b 


, 


56b 


/ 


57b 





60b 


1 


61b 


2 


62b 


3 


63b 


4 


64b 


5 


65b 


6 


66b 


7 


67b. 


8 


70b 


9 


71b 


\ 


72b 


» 


73b 


< 


74b 


= 


75b 


> 


.76b 


9 


77b 


@ 


100b 



A 


101b 


B 


101b 


C 


103b 


D 


104b 


E 


105b 


F 


106b 


G 


107b 


H 


110b 


I 


111b 


7 


112b 


K 


113b 


L 


114b 


M 


115b 


N 


116b 


O 


117b 


P 


120b 


Q 


121b 


R 


122b 


S 


123b 


T 


124b 


U 


125b 


V 


126b 


W 


127b 


X 


130b 


Y 


131b 


Z 


132b 


[ 


133b 


\ 


134b 


] 


135b 


t 


136b 


♦- 


137b 


' (left quote) 


140b 



■ ■BHaeiaB 

■ •iBHHaBM 

■ H 

■ ■ 

urn 

■ ■ 
■a 

■ H 



+ 



■a 

■ a 

■ a 



an 

BBaBHaaa 

aaaaBHHa 



+ 



Figure 1. Outline representation 
+ Origin 

+ Origin of next character 
Width = H + 



Figure 2. Raster representation 



vfv 



BBdy 



BBoy 



\/'\/' 

























PS 














































1 1 






















r^^ 








































niuan 




















rasa 


- 






































— 


— 


+ 




— 




13 






ntrM 






















nfi 






















mviu 


































































m:m 






















nu 






















nuu 






















Fjrj 
















e^o 


nuu 
















i^g^!;^ijy 


















yy£4j 


, 



















+ 



mi 




BBdx 




BQQ^ 



BBox 



Figures. Bounding box conventions. 
In the example, BBdx = 13, BBdy = 24, 
BBox = - 4, and BBoy =-13 



Figure 4. RLI coding example. 
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HI 
























1 






- 


- 


- 


- 




- 


- 


J 


1h 




















■ Ban 




















BB 
HB 

MB 


- 






- 


- 


- 


- 


: 


- 


- 


+ 


"CJH 

~HB 


a 
■ 






Huy 






















□ n 






















siaa 






















Htl 






















na 






















nun 




















nu 






















nna 






















taa 
















Bb ana 
















■ ■naa 




















1 


1 


fi 



















+ 



